System and Method for Securing a Credential via User and Server Verification

ABSTRACT

Systems and methods for securing a credential generated by or stored in an authentication token during an attempt to access a service, application, or resource are provided. A secure processor receives a credential from an authentication token and securely stores the credential. The secure processor then verifies the identity of the individual attempting to use the authentication token and cryptographically verifies the identity of the server being accessed. The credential is only released for transmission to the server if both the identity of the individual and the identity of the server are successfully verified. Alternatively, a secure connection is established between the secure processor and the server being accessed and a secure connection is established between the secure processor and a computing device. The establishment of the secure connections verifies the identity of the server. After the secure connections are established, the identity of the user is verified.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/367,293, filed Feb. 6, 2012, which is a continuation of U.S.application Ser. No. 11/648,647, filed Jan. 3, 2007, now U.S. Pat. No.8,112,787, which claims the benefit of U.S. Provisional Application No.60/755,419, filed Dec. 31, 2005, each of which are herein incorporatedby reference in their entirety.

FIELD OF THE INVENTION

This application relates generally to data communications and morespecifically to information security.

BACKGROUND OF THE INVENTION

Certain types of on-line services and applications are targets forhackers and other malicious individuals attempting to gain access tosensitive user information. This is particularly true for on-linefinancial applications such as Internet banking, on-line payment sites,and on-line brokerages. Common techniques used by hackers include theinstallation of viruses, Trojan horses, or spyware on a user's computer,phishing schemes, and man-in-the-middle attacks involving theinterception of communication from the user's computer and an externalserver or device.

Various forms of authentication are used to provide security for on-linetransactions. The forms of authentication are generally categorized inthree classes: something the user is (e.g., a biometric such as afingerprint), something the user has (e.g., a security token), andsomething the user knows (e.g., password). Security is strengthened byusing multiple forms of authentication (referred to as “multi-factor”authentication) to verify the identity of a user.

In the various schemes described above, a hacker attempts to access theauthentication data (referred to as a “credential”) associated with anauthentication factor. Because the identity of the server is notauthenticated during an access attempt, credentials are susceptible tohacking schemes involving establishment of an illegitimate servers. Forexample, in a phishing scheme, a user is tricked into entering hisauthentication credentials into a fake website having the look and feelof the legitimate site. The operator of the phishing website may thenuse those credentials to access the user's account and/or performunauthorized transactions.

In man-in-the middle schemes, communication between the user and aserver are intercepted. In other words, the user is led to believe thathe is in direct communication with the server and vice versa. Inactuality, the “man-in-the-middle” establishes separate connections withthe user's device and the server. As a result, the man-in-the middlesoftware logs all communication between the user's device and theserver. Thus, credential sent in the clear over the communicationsconnection between the user's device and the server are vulnerable.

Malicious code may also be surreptitiously installed on a user'scomputer. This malicious code may cause a user's keystrokes to bemonitored or may cause communications to be intercepted. Thus,credentials stored in the clear on a user's device are vulnerable tocertain forms of malicious code.

What is therefore needed are systems and methods for securing anauthentication credential via verification of the user and verificationof the server.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles of theinvention and to enable a person skilled in the pertinent art to makeand use the invention.

FIG. 1 is an exemplary operating environment, according to embodimentsof the present invention.

FIG. 2 depicts a flowchart of a method for securing a credential viauser and server verification, according to embodiments of the presentinvention.

FIG. 3 depicts a flowchart of an exemplary method for authenticating aserver using PKI, according to embodiments of the present invention.

FIG. 4 depicts a flowchart of an exemplary method for verifying a serverusing a challenge/response protocol, according to embodiments of thepresent invention.

FIG. 5 depicts a flowchart of an exemplary method for verifying a serverusing transport layer security (TLS) or secure sockets layer (SSL)protocols, according to embodiments of the present invention.

FIG. 6 depicts a flowchart of a method for securing a credential viauser and server verification, according to embodiments of the presentinvention.

The present invention will now be described with reference to theaccompanying drawings. In the drawings, like reference numbers canindicate identical or functionally similar elements. Additionally, theleft-most digit(s) of a reference number may identify the drawing inwhich the reference number first appears.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is an exemplary operating environment 100 for securing acredential via user and server verification, according to embodiments ofthe present invention. Exemplary operating environment 100 includes aplurality of tokens 102, computing devices 110 having integrated secureprocessors, a plurality of computing devices 120, a plurality ofexternal secure processing devices 130, a communications network 150,and a plurality of servers 160.

Token 102 is a portable module which is issued by a provider of aservice, application, or resource. For example, a financial institutionmay issue a user a security token to be used to make financialtransactions over the Internet. Token 102 is configured to provide theauthentication data necessary for the user to access to the requestedresource, service, and/or application offered by the provider.

Token 102 may be implemented in various physical forms depending on theneeds of the respective applications. For example, token 102 may be in aform that is easy to carry, similar to a plastic credit card, smartcard,building access card, fob, etc. Also, a token may take a form that maybe attached to or incorporated into another article. Examples of tokens102 include, without limitation, smartcards, credit cards, dongles,badges, biometric devices such as fingerprint readers, mobile devicessuch as wireless phones, or PDAs.

Token 102 may include an optional credential generator 104. In anembodiment, credential generator 104 generates a random or pseudo randomvalue (often referred to as a one-time password). The value may changeevery transaction or may change over time (e.g., at specific intervalsor randomly). If token 102 is a smartcard, credential generator 106 maybe configured to generate a monotonically increasing value for eachtransaction attempted by the user of the smartcard (referred to hereinas a “transaction code”). In an alternate embodiment, token 102 stores afixed credential in memory (not shown). The fixed credential may be ashared secret, a private key, or a secret key.

Computing device 110 includes a user interface 112, a network interface114, and an integrated secure processor 140. Computing device 120includes a user interface 112, a network interface 114, and a processor116. Unlike computing device 110, computing device 120 does not have anintegrated secure processor 140. Both computing device 110 and computingdevice 120 may include an interface for coupling with an external secureprocessing device 130 (interface not shown). Computing device 110 or 120is any device with a processor including, but not limited to, a personalcomputer, a laptop, a wireless phone, a personal digital assistant(PDA), or a personal entertainment device.

User interface 112 is configured to enable a user to interact withcomputing device 110 or 120 and to request access to remote applicationsand services. User interface 112 may include one or more output devicesincluding, but not limited to, a display, indication lights, and aspeaker. In addition, user interface 112 may include one or more inputdevices including, but not limited to, a keypad, button, pointingdevice, touch screen, audio device, and a soft-key-based menu. Forexample, authentication data such as a log-in/password pair may beentered via user interface 112.

Network interface 114 is configured to enable computing device 110 or120 to communicate with network 150. In an embodiment, network interface114 is a wired interface. In an additional or alternative embodiment,network interface 114 is a wireless interface.

Secure processing device 130 is a stand-alone device which may becoupled to computing device 110 or 120 to provide secure processingcapabilities. Secure processing device 130 may be a dongle (e.g., aUSB-based dongle) or any other device which can be coupled to acomputing device. Secure processing device 130 includes a secureprocessor 140.

Secure processor 140 provides the required cryptographic operations toencrypt, decrypt, and/or authenticate data that is sent or received bythe secure processor. Additionally, secure processor 140 securelymaintains information received from token 102 (e.g., credential) andreleases the information only after the user and server are verified. Inan embodiment, secure processor 140 includes a credential generationmodule 144. Credential generation module 144 is configured to generate acredential. In an embodiment, a credential is generated using atransaction code received from token 102. Alternatively, credentialgeneration module 144 uses seed information generated by or stored insecure processor 140 to generate a credential.

Secure processor 140 may comprise a processor, memory, dedicatedcryptographic hardware, and a token interface 142. In addition, secureprocessor 140 may incorporate other security mechanisms. For example,secure processor 140 may be configured to securely execute the code torelease or generate the credential. For example, secure processor 140may be configured to only execute secure (e.g., authenticated) code. Inan embodiment, secure processor 140 is designed to conform to a securityspecification relating to, for example, FIPS or TPM.

A security boundary associated with secure processor 140 may beestablished, for example, using hardware and/or cryptographictechniques. Hardware techniques for providing a security boundary mayinclude, for example, placing components within a single integratedcircuit. In addition, one or more integrated circuits may be protectedby a physical structure using tamper evident and/or tamper resistanttechniques such as epoxy encapsulation. Encryption techniques forestablishing a security boundary may include, for example, encryptingsensitive information before it leaves secure processor 140. For thispurpose, secure processor 140 may use one or more cryptographicprocessors and store the associated encryption/decryption keys in asecure memory internal to secure processor 140.

Secure processor 140 stores user authentication data such as a useridentifier, password, PIN, shared secret, and/or user biometric templateand also temporarily stores the credential received from the token. Thisdata may be stored in memory within the secure processor 140 eitherwithin the security boundary or external to the security boundary.Alternatively, secure processor 140 may store the information in anexternal memory in an encrypted form. The key(s) used to encrypt,decrypt, and/or authenticate the externally stored information may bemaintained with the security boundary of secure processor 140.

In an embodiment, secure processor 140 includes the capabilities togenerate an asymmetric key pair (public/private key pair). In analternative embodiment, the private key is “securely injected” into thesecure processor 140. In the secure injection embodiment, the entitywhich injects the private key must “forget” the private key to ensurethe integrity and privacy of the asymmetric key pair. In eitherembodiment, the private key does not leave the hardware securityboundary of processor 140 unless encrypted. An exemplary system andprocess for securely generating an asymmetric key pair or securelyinjecting a private key into a processor is described in detail in U.S.Patent Publication No. 2005/0166051, entitled “System and Method forCertification of a Secure Platform,” which is incorporated herein byreference in its entirety.

Token interface 142 is configured to communicate with token 102. In anembodiment, token interface 142 is a contact-based interface. In acontact-based interface, the secure processor 140 has one or moreelectrical connectors which make contact with electrical connectors ontoken 102 or smartcard 104. In addition or alternatively, tokeninterface 142 is contactless interface. For example, secure processor140 may communicate with a token 102 or smartcard 104 using radiofrequency identification (RFID) induction technology, low frequencyRFID, or near field communication (NFC) such as high frequency RFID, inaccordance with, for example, ISO 14443 and ISO 15693. In an embodiment,token interface 142 includes a smartcard reader.

In some embodiments, token interface 142 resides within the securityboundary associated with secure processor 140. In these embodiments,information received from token 102 such as the credential may besecurely maintained within secure processor 140. Additionally, thecredential generated by the token 102 may be encrypted before it iscommunicated outside the chip within which secure processor 140 isimplemented. As a result, information from the token 102 remainssecured, even if computing device 110 or 120 is compromised.

In an embodiment, computing devices 110 or 120 (or secure processor 140)directly access one or more servers 160 or 170 via a communicationsmedium 150. Communications medium 150 may be a public datacommunications network such as the Internet, a private datacommunications network, the Public Switched Telephone Network (PSTN), awireless communications network, or any combination thereof. Theinterface between the computing devices 110, 120 and communicationsnetwork 150 can be a wireless interface or a wired interface.

Server 160 hosts one or more resources, applications, and/or services162 to which a user is enrolled. Server 160 may comprise hardware and/orsoftware configured to provide a resource, service, or application. Forexample, a server may include a processing system that handles accessrequests, authenticates the requestor, and facilitates access to therequested resource, service, or application.

In an embodiment, server 160 includes a verification module 164.Verification module 164 is configured to validate that the credentialreceived is the expected credential. Verification module 164 includes analgorithm corresponding to the algorithm used to generate the code.

FIG. 2 depicts a flowchart 200 of a method for securing a credential viauser and server verification, according to embodiments of the presentinvention. Flowchart 200 is described with continued reference to theexemplary operating environment depicted in FIG. 1. However, flowchart200 is not limited to that embodiment. Note that some of the steps inflowchart 200 do not necessarily have to occur in the order shown.

Prior to step 210, a user enrolls or sets-up an account with a serviceprovider. In an illustrative example, the service provider is afinancial institution such as a bank, brokerage, credit union, etc. Theservice provider issues a token for use as an authentication mechanismwhen the user attempts to access certain resources or applications. Atthis point, or alternatively at the time of manufacture, the token isprogrammed to generate a credential or to store a fixed credential.

In step 210, a user initiates access to a resource, service orapplication 162 (referred to herein as “resource” for ease ofdescription) provided by or on-behalf of the service provider. In anembodiment, the resource allows the user to access his or her financialinformation or perform financial transactions over a public data network(e.g., Internet). A user may access service or application 162 via anysuitable computing device. For example, a user may use a standard webbrowser to access a webpage through which a user can gain access to thedesired application or service.

Alternatively, in step 210, a user initiates access to a resource,service, or application local to the computing device. For example, theuser may initiate access to the computing device itself.

In step 215, server 160 requests user-resource authentication data fromthe user. The user-resource authentication data includes a credentialgenerated by the token 102 (or optionally generated by secure processor140) and optionally log-in and password data established for thespecific resource.

By requiring a user to present the credential in addition to the log-inand password, a person who gained access to the log-in and password datawould not be able to access the resource at a later time because hewould not have access to the additional authenticator (i.e., thecredential). Also, a person who gained access to the log-in, password,and a credential value (e.g., via a phishing scheme, spyware, orman-in-the-middle attack) would not be able to log-in to the resource ata later time because the credential value varies randomly or pseudorandomly. Accordingly, at most, an unauthorized user may be able to usethe token to initiate one unauthorized access attempt using the data.Subsequent access attempts would be denied.

In step 220, a credential is communicated from token 102 to secureprocessor 140 and stored in a secure manner. The credential may be aone-time password generated by token 102, a transaction code generatedby a smartcard token, or a static credential stored within token 102. Inan embodiment the credential is not displayed by token 102.Communication is initiated by bringing token 102 into contact or intoproximity of token interface 112.

In step 230, computing device 110 or 120 requests release of thecredential from secure processor 140. The credential is only released ifthe identity of the user and the server are both verified.

In step 240, secure processor 140 verifies the identity of the user. Aswould be appreciated by persons of skill in the art, any technique forverifying the identity of a user can be used. Step 240 includes steps242-246.

In step 242, secure processor 140 requests authentication of the user.For example, secure processor 140 may cause computing device 110 or 120to request a password, PIN, or shared secret from the user. In analternative embodiment, secure processor 140 may cause computing device110 or 120 to request a current biometric scan of the user. Note thatthe user authentication data requested by secure processor 140 in step242 may be different than the user authentication data requested by theserver 160 in step 215.

In step 244, secure processor 140 receives authentication data from theuser.

In step 246, secure processor 140 verifies the received authenticationdata by comparing the received authentication data with the userauthentication data stored in secure processor 140 (or securely storedexternally to secure processor 140).

In step 250, secure processor 140 verifies the identity of server 160. Avariety of techniques can be used to verify the identity of server 160.For example, the identity of the server can be validated using publickey infrastructure (PKI). Exemplary PKI validation is described below inreference to FIG. 3. In an additional example, the identity of theserver can be verified using a challenge/response mechanism. Anexemplary challenge/response mechanism is described below in referenceto FIG. 4. In a further example, the identity of the server can beverified using the Transport Layer Security (TLS) or Secure Socket Layer(SSL) protocol.

In step 260, secure processor 140 releases the credential if validationof both the user and server is successful. In an embodiment, secureprocessor 140 generates the credential. In an alternative embodiment,the credential is received from the token and then released.

FIG. 3 depicts a flowchart 350 of an exemplary method for verifying theidentity of a server using public key infrastructure certificates,according to embodiments of the present invention. Flowchart 350 isdescribed with continued reference to the illustrative system of FIG. 1.However, flowchart 350 is not limited to that embodiment. Note that somesteps in flowchart 350 do not have to occur in the order shown.

Prior to step 352, an asymmetric key pair (e.g., public/private keypair) and a digital certificate are generated for server 160. Thedigital certificate binds the identity of the certificate owner (i.e.,server 160) to a public/private key pair. The digital certificateincludes the public key of server 160, a name or other identifier forsecure processor, an expiration date, serial number, and identificationof organization that issued the certificate. The certification authoritysigns the digital certificate using its private key. As would berecognized by persons of skill in the art, any technique for generatinga signed certificate can be used with the present invention. Note thatthe public key of the certification authority must be publicly availableto enable validation of the secure processor certificate.

In addition, prior to step 352, secure processor 140 may obtain andstore the public key for server 160. Alternatively, the secure processorobtains the public key for server 160 as needed.

In step 352, secure processor 140 requests authentication of server 160.

In step 354, server 160 transmits a message including its digitalcertificate to server 160. Note that the message in the exchange of step352 between server 160 and secure processor 140 may include additionalinformation to deter man-in-the-middle and replay attacks.

In step 356, secure processor 140 validates the received certificate. Instep 356 (or prior to step 356), secure processor 140 obtains the publickey of the certification authority which issued the certificate toserver 160. Secure processor 140 then uses the public key of thecertification authority to verify the signature included with thedigital certificate. If the certificate is authentic, operation proceedsto step 260.

FIG. 4 depicts a flowchart 450 of an exemplary method for verifying theidentity of a server using a challenge/response protocol, according toembodiments of the present invention. Flowchart 450 is described withcontinued reference to the exemplary operating environment depicted inFIG. 1. However, flowchart 450 is not limited to that embodiment. Notethat some of the steps in flowchart 450 do not necessarily have to occurin the order shown.

In step 451, secure processor 140 generates a random value (or nonce) asa challenge and transmits the challenge to server 160.

In step 452, server 160 forms a hash value of its identification, thereceived random value, and optionally a random value (or nonce)generated by server 160.

In step 453, server 160 encrypts the hash value with its private key toform a digital signature.

In step 454, server 160 transmits the digital signature, random valuegenerated by server 160 (server nonce), and identification to secureprocessor 140.

In step 455, secure processor 140 decrypts the signature with the publickey for server 160. The public key may have been previously loaded intosecure processor 140 (e.g., from a certificate generated by a serverthan authorized use of token). Alternatively, secure processor 140 mayobtain the public key from a public directory when thechallenge/response protocol is initiated.

In step 456, secure processor 140 forms a hash value of theidentification, the generated random value, and optionally the servernonce. Steps 445 and 446 may occur substantially in parallel.

In step 457, secure processor 140 compares the hash values generated insteps 455 and 456. If the two values match, server 160 is successfullyauthenticated.

The embodiment described in FIG. 4 has advantages in that the challengeis validated in real-time. For example, the user of currently generatedrandom numbers helps to ensure that a previously issued challenge is notbeing replayed by an unauthorized server in an attempt to obtain thecurrent token value. As would be appreciated by persons of skill in theart, other challenge/response protocols can be used with the presentinvention.

FIG. 5 depicts a flowchart 550 of an exemplary method for verifying theidentity of a server using transport layer security (TLS) or securesockets layer (SSL) protocols, according to embodiments of the presentinvention. Flowchart 550 is described with continued reference to theexemplary operating environment depicted in FIG. 1. However, flowchart550 is not limited to that embodiment. Note that some of the steps inflowchart 550 do not necessarily have to occur in the order shown.

Transport layer security (TLS) and secure sockets layer (SSL) arecryptographic protocols for providing secure communication. SSL is thepredecessor of TLS. TLS and SSL are used for Internet applications andservices such as web applications and e-mail. Flowchart 550 is intendedto apply to both TLS and SSL protocols. As would be appreciated bypersons of skill in the art, the implementation of flowchart 550 for TLSmay vary from the implementation for SSL.

In step 551, secure processor 140 transmits a client hello message toserver 160. The client hello message includes a time stamp, a randomnumber, and a CipherSuite list. The CipherSuite list includescombinations of cryptographic algorithms supported by secure processor140 in order of preference. In addition, each CipherSuite includes a keyexchange algorithm, a bulk encryption algorithm (including secret keylength) and a message authentication code (MAC) algorithm. The clienthello message may also include a list of compression algorithmssupported by secure processor 140 in order of preference.

In step 552, server 160 responds to the client hello message with aserver hello message if an acceptable set of algorithms was provided inthe client hello message. The server hello message includes a randomnumber (independently generated from random number in client hellomessage) and a CipherSuite. The CipherSuite is a single cipher suiteselected by the server from the list of cipher suites included in theclient hello message. The server hello message may also include acompression method indicating the single compression algorithm selectedby the server from the list of compression methods in the client hellomessage.

In step 554, server 160 transmits its digital certificate. The type andformat of the digital certificate is determined by the selected ciphersuite's key exchange algorithm. The server may optionally send a serverkey exchange message following the certificate message if thecertificate message does not contain adequate information to allow theclient to exchange a premaster secret. The server may also optionallytransmit in this step a request for secure processor's 140 certificate.

In step 555, secure processor 140 validates the provided certificate.

In step 556, secure processor 140 transmits a client key exchangemessage if the provided server certificate is validated. With the clientkey exchange message, the premaster secret is set. For example, if RSAis being used for key agreement and authentication, the premaster secretis encrypted using the server's public key from the server's certificateor a temporary key provided in the server key exchange message and sentin the client key exchange message. If a different algorithm is beingused, parameters may be sent in the client key exchange message whichallow each side to agree upon the premaster secret. Note that in step546, if secure processor's 140 certificate was requested, a clientcertificate message is sent prior to the transmission of the client keyexchange message.

In step 558, secure processor 140 and server 160 begin to securelyexchange application data.

FIG. 6 depicts a flowchart 600 of a method for securing a credential viauser and server verification, according to embodiments of the presentinvention. In the method of FIG. 6, secure processing device 130 acts asan TLS or SSL proxy establishing an TLS or SSL connection with computingdevice 120 and a separate TLS or SSL connection with server 160. In thismethod, secure processing device 130 may, in effect, perform some of thefunctionality of a web browser. Flowchart 600 is described withcontinued reference to the exemplary operating environment depicted inFIG. 1. However, flowchart 600 is not limited to that embodiment. Notethat some of the steps in flowchart 600 do not necessarily have to occurin the order shown.

In step 610, a user initiates access to a resource, service orapplication 162 (referred to herein as “resource” for ease ofdescription) provided by or on-behalf of the service provider. In anembodiment, the resource allows the user to access his or her financialinformation or perform financial transactions over a public data network(e.g., Internet). A user may access service or application 162 via anysuitable computing device. For example, a user may use a standard webbrowser to access a webpage through which a user can gain access to thedesired application or service.

In step 620, secure processor 140 in secure processing device 130establishes a secure connection with server 160. For example, computingdevice 120 may request that secure processor 140 request a secureconnection based on the web site address entered by the user. In anembodiment, the secure connection is established using TLS or SSL. Anexemplary method for establishing a secure connection using TLS or SSLis described above in reference to FIG. 5.

In step 630, secure processor 140 in secure processing device 130establishes a secure connection with computing device 120. In anembodiment, the secure connection is established using TLS or SSL. Anexemplary method for establishing a secure connection using TLS or SSLis described above in reference to FIG. 5.

In step 640, server 160 requests user-resource authentication data fromthe user. The user-resource authentication data includes a credentialgenerated by the token 102 (or optionally generated by secure processor140) and optionally log-in and password data established for thespecific resource.

In step 650, a credential is communicated from token 102 to secureprocessor 140 in secure processing device 130 and stored in a securemanner. The credential may be a one-time password generated by token102, a transaction code generated by a smartcard token, or a staticcredential stored within token 102. Communication is initiated bybringing token 102 into contact or into proximity of token interface112.

In step 660, secure processor 140 verifies the identity of the user. Aswould be appreciated by persons of skill in the art, any technique forverifying the identity of a user can be used. Step 660 includes steps662-667.

In step 662, secure processor 140 requests authentication of the uservia the established secure connection with computing device 120. Forexample, secure processor 140 may cause computing device 110 or 120 torequest a password, PIN, or shared secret from the user. In analternative embodiment, secure processor 140 may cause computing device110 or 120 to request a current biometric scan of the user. Note thatthe user authentication data requested by secure processor 140 in step242 may be different than the user authentication data requested by theserver 160 in step 640.

In step 664, secure processor 140 receives authentication data from theuser via the established secure connection.

In step 667, secure processor 140 verifies the received authenticationdata by comparing the received authentication data with the userauthentication data stored in secure processor 140 (or securely storedexternally to secure processor 140).

In step 670, secure processor 140 transmits the credential to server 160via the established secure connection between secure processing device130 and server 160 if validation of the user is successful. In anembodiment, secure processor 140 generates the credential. In analternative embodiment, the credential is received from the token. Notethat in this embodiment, secure processor 140 verified the identity ofthe server when the TLS or SSL connection was established.

An advantage of the approach of FIG. 6 is that the credential is neverpresented in the clear. Instead, the credential is only sent betweensecure processor and server via a secure connection. Also, thecredential is not sent to user's computing device 120. Therefore, thecredential will not be compromised by any malicious code operating onthe user's computing device.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be apparent to persons skilledin the relevant art that various changes in form and detail can be madetherein without departing from the spirit and scope of the invention.Thus, the breadth and scope of the present invention should not belimited by any of the above-described exemplary embodiments, but shouldbe defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A method for securing a credential during anattempt to access a network service, comprising: transferring acredential from an authentication token to a secure processor using nearfield communication (NFC); storing the credential in the secureprocessor; authenticating an identity of an individual presenting theauthentication token; cryptographically authenticating a serverassociated with the network service; and releasing the credential to theserver if the identity of the individual is successfully authenticatedand the server is successfully authenticated.